home *** CD-ROM | disk | FTP | other *** search
/ Freaks Macintosh Archive / Freaks Macintosh Archive.bin / Freaks Macintosh Archives / Internet / TCPip / IntrotoPacketFragmentation.txt < prev    next >
Encoding:
Text File  |  1999-01-28  |  4.5 KB  |  83 lines  |  [TEXT/LMAN]
  1. ***********************************************************************
  2. ADVISORY: TCP packet fragment attacks against firewalls and filters
  3.   System: TCP/IP networks  
  4.   Source: http://all.net, Dr. Frederick B. Cohen
  5. ***********************************************************************
  6.  
  7. Packet Fragmentation Attacks
  8.  
  9. Introduction to Packet Fragmentation
  10.  
  11. Packet fragmentation is the part of the Internet Protocol (IP) suite of
  12. networking protocols that assures that IP datagrams can flow through any
  13. other sort of network. (For details, see Internet Request For Comments 791
  14. (rfc791) and are available and searchable in electronic form from Info-Sec
  15. heaven on the World-Wide-Web at http://all.net, through gopher service at
  16. all.net, or by ftp service from rs.internic.net.) Fragmentation works by
  17. allowing datagrams created as a single packet to be split into many smaller
  18. packets for transmission and reassembled at the receiving host.
  19.  
  20. Packet fragmentation is necessary because underlying the IP protocol, other
  21. physical and or logical protocols are used to transport packets through
  22. networks. A good example of this phenomena is on the difference between
  23. Ethernet packets (which are limited to 1024 bytes), ATM packets (which are
  24. limited to 56 bytes), and IP packets which have variable sizes up to about
  25. 1/2 million bytes in length.
  26.  
  27.  
  28. The only exception to this rule is in the case of an internet datagram
  29. marked don't fragment . Any internet datagram marked in this way is
  30. supposed to not be fragmented under any circumstances. If internet
  31. datagrams marked don't fragment cannot be delivered to their destination
  32. without being fragmented, they are supposed to be discarded instead. Of
  33. course, this rule doesn't have to be obeyed by the IP software actually
  34. processing packets, but it is supposed to be.
  35.  
  36. How Packet Reassembly Attacks Work
  37.  
  38. The packet fragmentation mechanism leads to attacks that bypass many
  39. current Internet firewalls, but the reason these attacks work is not
  40. because of the way fragmentation is done, but rather because of the way
  41. datagrams are reassembled.
  42.  
  43. Datagrams are supposed to be fragmented into packets that leave the header
  44. portion of the packet intact except for the modification of the fragmented
  45. packet bit and the filling in of an offset field in the IP header that
  46. indicates at which byte in the whole datagram the current packet is
  47. supposed to start. In reassembly, the IP reassembler creates a temporary
  48. packet with the fragmented part of the datagram in place and adds incoming
  49. fragments by placing their data fields at the specified offsets within the
  50. datagram being reassembled. Once the whole datagram is reassembled, it is
  51. processed as if it came in as a single packet.
  52.  
  53. According to the IP specification, fragmented packets are to be reassembled
  54. at the receiving host. This presumably means that they are not supposed to
  55. be reassembled at intermediate sites such as firewalls or routers. This
  56. decision was made presumably to prevent repeated reassembly and
  57. refragmentation in intermediate networks. When routers and firewalls
  58. followed the rules, they found a peculiar problem.
  59.  
  60. The way firewalls and routers block specific services (such as telnet )
  61. while allowing other services (such as the world wide web http service) is
  62. by looking into the IP packet to determine which Transfer Control Protocol
  63. (TCP) port is being used. If the port corresponds to 80, the datagram is
  64. destined for http service, while port 23 is used for telnet . In normal
  65. datagrams, this works fine. But suppose we didn't follow the rules for
  66. fragmentation and created improper fragmented packets? Here's what one
  67. attacker did:
  68.  
  69.    *  Create an initial packet which claims to be the first fragment of a
  70.      multi-packet datagram. Specify TCP port 80 in the TCP header so it
  71.      looks like a datagram going to http service, which is allowed to pass
  72.      the firewall.
  73.    *  The firewall passes the packet to the host under attack and passes
  74.      subsequent packet fragments in order to allow the destination host to
  75.      reassemble the packet.
  76.    *  One of the subsequent packets has an offset of 0 which causes the
  77.      reassembler to overwrite the initial part of the IP packet. This is
  78.      the part of the IP packet that specifies the TCP port. The attacker
  79.      overwrites the IP port number which was originally 80 with a new port
  80.      number such as 23, and is now granted telnet access to the host under
  81.      attack despite the firewall that is supposed to block the service.
  82.  
  83.